Introduce L1ScoutingNanoAOD for Run3 #48163
Conversation
|
cms-bot internal usage |
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-48163/44934
|
|
enable nano |
|
please test |
|
-1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-43d56f/46799/summary.html This pull request cannot be automatically merged, could you please rebase it? |
patinkaew
force-pushed
the
l1scouting_nano_dev_15_1_0_pre3
branch
from
fe95b32 to
4fdcdbc
Compare
cmsbuild
added
tests-pending
code-checks-pending
and removed
tests-rejected
code-checks-approved
labels
|
Hi @ftorrresd, Sorry for a delay. I just fix the merge conflict. Please note that the workflow numbers for L1ScoutingNano have changed (since BPHNano workflow in 140X was removed in master). Best, |
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-48163/45278
|
|
+1 Size: This PR adds an extra 24KB to repository Comparison SummarySummary:
NANO Comparison SummarySummary:
Nano size comparison Summary:
|
|
Hi @AdrianoDee, @Moanwar, @cmsbuild, @DickyChant, @emeschi, @ftorrresd, @hqucms, @miquork, @smorovic, @srimanob, @subirsarkar Are you able to review and/or sign please? Thanks a lot! Thomas |
|
+1 |
|
+Upgrade |
|
+1 |
|
+pdmv |
cmsbuild
added
fully-signed
pdmv-approved
and removed
pending-signatures
pdmv-pending
labels
|
This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @mandrenguyen, @rappoccio, @antoniovilela, @sextonkennedy (and backports should be raised in the release meeting by the corresponding L2) |
|
+1 |
|
|
||
| #include "oneapi/tbb/task_arena.h" | ||
|
|
||
| class OrbitNanoAODOutputModule : public edm::one::OutputModule<> { |
There was a problem hiding this comment.
Sorry, I didn't realize this part until it broke compilation against ROOT master (see #48720 for a fix).
I'm curious what is the planned maintenance model wrt. NanoAODOutputModule given that some amount of non-trivial code is currently "shared" by copying it (i.e. any similarity can be thought of accidental). Are there parts that should be really shared, or is the future of these two components completely disjoint?
Also, who will port/migrate this module to RNTuple in the future?
There was a problem hiding this comment.
Hi Matti,
Sorry for a delayed response. We discussed this a bit during last week L1 Scouting meeting 19.08.2025.
Thank you for the fix and sorry that I didn't catch the deprecated constants earlier. Since OrbitNanoAODOutputModule shares lots of code with NanoAODOutputModule, it would be optimally not to hard-copy to avoid code duplication and if there is a change in NanoAODOutputModule, OrbitNanoAODOutputModule will be changed accordingly (for example, in this case). Hence, the current implementation is not quite optimal and leaves this issue on deprecated constants unchecked. However, I would expect that NanoAODOutputModule will need to be refactored and personally, I wouldn't want to do this during data-taking so I hope the refactor will be done after Run3 finishes.
OrbitNanoAODOutputModule handles translating from orbit-based collection used in L1 scouting to event-based. From my understanding, CMSSW processes event-by-event. In the L1 scouting case, this is orbit-by-orbit. Hence, we use OutputModule to handle changing to event-based when writing to TTree. Do you have any suggestions/ideas on how we can use the standard NanoAODOutputModule?
Regarding porting this module to RNTuple, I'm not very familiar with RNTuple nor RNTupleOutputModule yet and not following the latest development, but I would be happy to implement it if I'm still working with CMS (hopefully). Otherwise, I will compile some documentation for the L1Scouting group so someone will be able to take over as well.
@gpetruc also agrees with this and suggested that we refactor and migrate to RNTuple at the same time. He can also offer to help.
There was a problem hiding this comment.
However, I would expect that NanoAODOutputModule will need to be refactored and personally, I wouldn't want to do this during data-taking so I hope the refactor will be done after Run3 finishes.
Ok.
Do you have any suggestions/ideas on how we can use the standard NanoAODOutputModule?
No. I'd look into abstracting the common parts into components that could be shared between this and the NanoAODOutputModule.
Regarding porting this module to RNTuple, I'm not very familiar with RNTuple nor RNTupleOutputModule yet and not following the latest development, but I would be happy to implement it if I'm still working with CMS (hopefully). Otherwise, I will compile some documentation for the L1Scouting group so someone will be able to take over as well.
Ok. The RNTuple-based NanoAOD is still in the works (@ariostas), so it might be useful to either wait for that dust to settle, have this use case included in that work. In any case all this is eventually up to @cms-sw/xpog-l2 (and possibly @cms-sw/daq-l2). I only got concerned of somewhat complicated code being copied around, and if that would have potential to cause maintenance issues in the future.
10 participants
PR description:
Please also note contributions from @gpetruc, @Mmiglio for initial and important components of L1ScoutingNano as well as L1Scouting team for numerous valuable feedbacks.
This PR introduces L1ScoutingNanoAOD workflow for Run3. For L1Scouting data, each processing event is actually an orbit (in OrbitCollection), different OutputModule is needed to convert orbits to bunch crossings (bx).
Some key features:
OrbitNanoAODOutputModuleis analogous toNanoAODOutputModuleand is used to convert orbits to bxs.OrbitFlatTableis analogous tonanoaod::FlatTableand contains offsets of each bx in an orbitSimpleOrbitFlatTableProduceris analogous toSimpleFlatTableProducerand has all functionalities ofSimpleFlatTableProducer.Two custom NanoAOD flavours are added:
@L1Scoutfor ZeroBias stream and@L1ScoutSelectfor Selection stream.Event content files (html) can be found here on CERNBOX.
PR validation:
Pass all tests from
scram b runtests use-ibeos.Two relval_nano workflows are added for each flavour.
Pass these two workflows from
runTheMatrix.py -l 2500.240,2500.241If this PR is a backport please specify the original PR and why you need to backport that PR. If this PR will be backported please specify to which release cycle the backport is meant for:
This is not a backport.